System for Facilitating Payments

ABSTRACT

A system (and corresponding method) for facilitating an online transaction initiated by a client at an online address, the system comprising a payment token having a unique identification factor, an authorisation gateway and a data processing unit, the authorisation gateway being adapted to receive the online address and to transmit it to the data processing unit, and the data processing unit being adapted to receive the online address and the unique identification factor and to allow or deny the said transaction or require a further confirmation step based on the online address, the unique identification factor and a set of rules.

FIELD OF THE INVENTION

The present inventive concept relates to apparatus and methods to facilitate real-time financial transactions, especially at online point of sale (POS) transactions.

BACKGROUND TO THE INVENTION

Online consumer sales growth is facilitated by multiple channels through which customers can browse, select and purchase goods and services. Goods and services are marketed and sold through a number of mobile applications and web browsers.

In order for customers to pay for the goods and services they purchase, on-line merchants accept payment instruments such as debit and credit cards as well as well known payment methods such as PayPal. Merchants use their own websites or those of marketplaces to sell their goods and services identifiable by their unique URL/SESSION IDs (Uniform Resource Locators) commonly called ‘web addresses’.

SUMMARY OF INVENTION

The present inventive concept provides a system for facilitating an online transaction initiated by a client at an online address, the system comprising a payment token having a unique identification factor, an authorisation gateway and a data processing unit, the authorisation gateway being adapted to receive the online address and to transmit it to the data processing unit, and the data processing unit being adapted to receive the online address and the unique identification factor and to allow or deny the said transaction or require a further confirmation step based on the online address, the unique identification factor and a set of rules.

The said further confirmation step may comprise a notification to the client of certain information.

The online address may be that of a merchant (for example a retailer). An online address may comprise a Uniform Resource Locator, Uniform Resource Identifier and/or a Session ID. A Session ID may be conveyed by way of a cookie.

The inventive concept combines two elements of transaction technology to provide a new and advantageous system.

Payment tokens are widely used, but generally the unique identification factor is transmitted to an acquiring institution and subsequently to an issuing institution with only discrete data according to a standard message format. Thus, previously, an issuing institution would not receive information relating to the online address via which the online transaction is initiated by the client. For many clients and issuing institutions this is not problematic.

However, advantageous functionality can be provided when the system is adapted as described above.

For example, a requirement for an additional payment authorisation security step may be introduced. This can reduce the risk of fraudulent transactions. Furthermore, an interested party may offer benefits or incentives to the client.

Thus, a client may choose to use a particular online portal to initiate the transaction. The system can track that initiating portal to provide information thereon to the issuing institution.

It is generally understood that a client is free (given the diversity and open nature of the public internet) to choose which portal is used to initiate a transaction. A retailer's online offering may therefore be accessed by a number of different routes. If a retailer and issuing authority are able to confirm the portal used to initiate a transaction, then they can capture potential benefits from—and encourage the use of—particular portals.

Thus, a link between a transaction approval and the online address is created. Importantly, this enables an issuing authority to confirm whether a particular portal has been used to initiate a transaction.

An issuing authority might derive a benefit from this by being able to offer payment terms agreed between the issuing authority and a particular retailer or operator of a portal. A client might derive a benefit from a rebate or discount incentive. In either exemplary case, a pre-existing agreement between a retailer and issuing authority can provide a benefit to all parties—but only as long as the transaction is tracked in the way described.

For example, a particular portal may be established by an affiliate link between a retailer and issuing authority.

The payment token may be a payment card, optionally a “virtual” payment card. A virtual payment card is a set of account details which may never be manifested on a physical payment card. A payment token typically comprises an account number, expiry date and possibly further authentication information.

One advantage of offering a virtual payment card in combination with the features of the present inventive concept is additional tracking of a transaction by providing a specific token for a specific task, period, or the like.

The authorisation gateway may be a “3D Secure”® authentication or similar.

The inventive concept thus combines virtual payment cards (tokens) and 3D Secure and to transparently transport information to the issuing authority between mutually independent transactions. Furthermore, the invention transforms the virtual payment card standard digital information by embedding the mandated URL/SESSION ID without the need for the card schemes, acquirers or payment gateways to make any modifications to their system or message formats.

This enables the tracking of use of affiliate links between a retailer, issuing authority and consumer. In effect, it enables a closed loop. The inventive concept enables the issuing authority to reject a transaction if it has not been initiated through the portal required by such an affiliate link.

The invention describes how it can be used to ensure that rules set prior to transacting are enforced thus opening up a myriad of possible options or benefits that simply could not be offered otherwise.

Advantages and possible implementations of the present inventive concept will now be set out in further detail.

In order for customers to pay for the goods and services they purchase, online merchants accept payment instruments such as debit and credit cards as well as well known payment methods such as PayPal®. Merchants use their own websites or those of marketplaces to sell their goods and services identifiable by their unique URL/SESSION IDs (Uniform Resource Locators) commonly called ‘web addresses’.

When a debit or credit card is used to effect a payment instruction, the transaction information, inclusive of the amount to be paid is sent to the merchant's acquiring bank or payment gateway which then requests an authorisation from the institution that issued the credit or debit card to the transacting client (card issuer). Issuing institutions would not previously vet the URIs (Uniform Resource Identifiers) of the merchants from which transactions originate.

It is clear therefore that merchant stores can be accessed via different URL/SESSION IDs depending on the browser's clients use at various times. The access path selected is in most cases irrelevant to clients but, if required, clients always have the choice to choose the portal/URL/SESSION ID through which the merchant will be accessed. For example, a client may wish to purchase a pair of shoes via a portal that offers discounts. Such discounts are in some cases negotiated by an affiliate of the merchant concerned and can thus only be claimed by a client if the purchase is performed via the affiliate's URL/SESSION ID.

When a client accesses a merchant's URL/SESSION ID directly, only this merchant can offer a discount. When the same client purchases the goods via an affiliate of said merchant, such affiliate may be able to offer the client a discount and/or cashback based on its affiliate/merchant agreement. Clients can thus search the internet for the best discounts and purchase the goods they require via their associated website.

There are currently no known technological methods to control an authorisation based on the specific URL/SESSION ID a client may have used to make purchases. The reason for this lack of control is twofold, a) the issuing institution will generally not deny a transaction unless it does not comply with its standard financial terms (e.g. credit limit) and b) it is the client who decides from which web-site the goods will be purchased based on criteria that are not the business of issuing institutions.

The Internet is an open system and thus it would be intuitively wrong to obligate clients to use specific URL/SESSION IDs to effect purchases, unless of course clients were advised beforehand that such restriction is necessary for them to access certain financial products or derive benefits. Clients therefore would decide on the URL/SESSION IDs they wished to use based on the benefits these would attract.

For example, an organisation may wish to provide short term finance to its clients but only if specific affiliate links are utilised. The credit provided may be financially beneficial to clients as the credit provider would derive income streams from the merchants with which they have concluded affiliate agreements. Without these new income streams, the credit provider may not be in a position to offer the credit line requested on preferential terms.

Clients may, inadvertently or knowingly access the merchant's website via an URL/SESSION ID that are not affiliated with the credit provider. If and when this occurs, the credit provider may wish to decline the purchaser and therefore refuse to provide the credit line requested or advise the client that the financial terms of the credit line such as interest, fees, repayment periods, etc. have changed as a result of the client's action (URL/SESSION ID selection). Thus, a notification may be made.

The previously missing link (in other words, the contribution of the present inventive concept) is that the schemes' payment authorisation function cannot be tracked as needed and the merchant is thus is not aware of the agreement previously entered into by the client and the credit provider (issuing authority) regarding the use of a specific URL/SESSION ID. This lack of historical tracking might allow the client to make use of the credit provided using any URL/SESSION ID and thus bypass the credit provider's rules.

This inventive concept resolves the above dilemma elegantly by creating an trackable link between the credit approval process and the URL/SESSION ID to be utilised. This link is created when the client selects the merchant store and the goods to be purchased.

The first part of the solution is achieved by issuing a virtual card, constructed in such a way as to, on the one hand, adhere to the card schemes' format and on the other, to embed in the issuer's proprietary data fields, the URL/SESSION ID from which the goods should be acquired. This ensures that when this virtual card is utilised in the future to make a purchase, the URL/SESSION ID which was to be used is provided to the authorisation authority, in this case, the credit provider (issuing authority).

The inventive concept thus creates an irrefutable audit trail of the client's agreement embedded in the virtual card itself thus ensuring that the URL/SESSION ID information cannot be lost and can always finds its way back to the authorisation (issuing) authority.

The inventive concept further addresses the problem associated with providing the URL/SESSION ID, on which the transaction is actually being affected, to the authorising authority so that it can perform a comparison. It must be noted that previous card schemes do not and cannot currently provide this information as part and parcel of their standard ISO 8583 message formats. It was thus not previously possible for the authorisation (issuing) authority to be made aware of the URL/SESSION ID being used at the time the transaction is performed.

This inventive concept resolves this problem by utilising the 3D secure functionality as a means of obtaining the URL/SESSION ID on which the transaction is being conducted. At check-out, clients are asked to enter their 16 digit card number (PAN—primary account number), expiry date and the card verification value (CVV). Once these values have been entered, the transaction is sent for authorisation through the acquirer's system or the merchant's payment gateway. If 3D secure is mandated by the issuing institution, a 3D secure portal is activated through which the client can be identified and validated.

The 3D portal is provided by the issuing institution which can therefore derive the URL/SESSION ID being used by the client. In addition to providing additional client security, 3D secure is utilised to feed-back to the issuer, the virtual card details as well as the URL/SESSION ID where these were captured.

The authorising institution (in this case, the credit provider) can now compare the URL/SESSION IDs and either a) authorise the transaction, b) deny the transaction or/and c) advise the client via the 3D portal that the wrong URL/SESSION ID is being used thus allowing the client to take remedial action.

FIG. 1 shows an exemplary payment card in line with EMV standards, and shows how specific data can be embedded into a cryptogram and repurposes the result to look and function as a standard EMV token. Thus, a process where a scheme issued BIN 401 is combined with a system generated cryptogram comprising 16 digits (making use of public/private key pair) generated using identification and authentication data such as, but not limited to an account identifier 404, session ID 405, a signature 406 generated with the customers private key, and a check digit make up what would traditional be known as a PAN, CVV and Expiry date. 

1. A system for facilitating an online transaction initiated by a client at an online address, the system comprising a payment token having a unique identification factor, an authorisation gateway and a data processing unit, the authorisation gateway being adapted to receive the online address and to transmit it to the data processing unit, and the data processing unit being adapted to receive the online address and the unique identification factor and to allow or deny the said transaction or require a further confirmation step based on the online address, the unique identification factor and a set of rules.
 2. A system according to claim 1, wherein the said further confirmation step comprises a notification to the client of certain information.
 3. A system according to claim 1, wherein a link between a transaction approval and the online address is created.
 4. A system according to claim 1, wherein the payment token comprises at least an account number and an expiry date.
 5. A system according to claim 4, wherein the payment token further comprises further authentication information.
 6. A method for facilitating an online transaction initiated by a client at an online address, comprising the steps of: at check-out, clients are asked to enter their 16 digit card number (PAN—primary account number), expiry date and the card verification value (CVV); once these values have been entered, the transaction is sent for authorisation through the acquirer's system or the merchant's payment gateway; an authorisation gateway is activated through which the client can be identified and validated. 